Location-independent packet routing and secure access in a short-range wireless networking environment

ABSTRACT

The present invention provides methods, systems, and computer program instructions for providing location-independent packet routing and secure access in a wireless networking environment (such as that encountered within a building), enabling client devices to travel seamlessly within the environment. Each client device uses a constant address. An address translation process that is transparent to the client and server is automatically performed as the device roams through the environment, enabling efficient client migration from one supporting access point to another. The secure access techniques provide user-centric authentication and allow policy-driven packet filtering, while taking advantage of encryption capabilities that are built in to the hardware at each endpoint.

RELATED APPLICATIONS

The application is a continuation of U.S. application Ser. No.10/688,576, filed Oct. 18, 2003, which is a continuation of U.S.application Ser. No. 09/657,745, filed Sep. 8, 2000 (now U.S. Pat. No.6,691,227). Each of these applications is hereby incorporated herein byreference.

The application is related to U.S. application Ser. No. 09/637,742,filed Aug. 11, 2000 (now U.S. Pat. No. 6,633,761), entitled “EnablingSeamless User Mobility in a Short-Range Wireless NetworkingEnvironment”, which is hereby incorporated herein by reference.

FIELD OF THE INVENTION

The present invention relates to computer networks, and moreparticularly to methods, systems, and computer program instructions forrouting packets and providing secure network access for short-rangewireless computing devices

BACKGROUND OF THE INVENTION

In recent years, various short-range wireless network communicationstechnologies, notably IEEE 802.11 and Bluetooth, have emerged to enableportable devices (such as laptops, cellular phones, personal digitalassistants or PDAs, etc.) to communicate both with each other and withwide-area networking environments. (IEEE 802.11 is a standard of theInstitute for Electrical and Electronics Engineers, which was approvedin 1997 for wireless Local Area Network, or LAN, signaling andprotocols. 802.11 addresses frequency hopping spread spectrum radio,direct sequence spread spectrum radio, and infrared light transmissions.Bluetooth is a specification for short-range wireless connectivity thatis aimed at unifying telecommunications and computing. More informationon these specifications can be found on the Internet at www.ieee.org andwww.bluetooth.com, respectively.)

The problem of host mobility within this environment is well known inthe prior art, and several solutions have been defined to address theproblem. Among these are Mobile IP (Internet Protocol), an end-to-endTCP (Transmission Control Protocol) re-mapping approach, and the HAWAII(Handoff-Aware Wireless Access Internet Infrastructure) system. Each ofthese solutions, along with a brief summary of their limitations ordisadvantages in terms of location-independent packet routing and secureaccess, will now be described.

In the Mobile IP environment, each device is assigned to a static,global IP address. The device is also assigned to a fixed Home Agent(HA) on its home network. When the device roams, the following stepsoccur: (1) the device locates a Foreign Agent (FA) host on the remotenetwork and establishes communication with it, and provides the FA withthe identity of the HA; (2) the FA initiates a handshake with the HA;(3) packets destined for the client are received by the HA, which thentunnels them to the FA, which then forwards them to the device; (4)packets generated by the client are intercepted by the FA, which thentunnels them to the HA, which then forwards them to the intendeddestination. However, optimizations have been made to Mobile IP to allowthe FA to transmit packets directly to the intended destination insteadof sending them via the HA.

Mobile IP has a number of disadvantages and limitations, however. The“IP-inside-IP” tunneling requires that additional header material isadded to the packet, and it also requires the recalculation of at leasta new IP header checksum (for the additional IP header material). Theseoperations require extra memory accesses at the HA and/or FA. On someoperating systems, the checksum calculation may not be incremental (andtherefore may require accessing every byte in the IP header). On someoperating systems, adding header material requires that the entirepacket be copied to a new buffer, requiring access to every byte in thepacket. Packet tunneling between the HA and FA also increases the packetsize. This in turn increases bandwidth consumption and may requireadditional fragmentation and re-assembly of the original IP packets(essentially introducing new packet loss conditions). Tunneling cantherefore cause performance degradation. Furthermore, the tunnelingbetween the HA and FA introduces a routing inefficiency, since allinbound packets must be routed between the two hosts, even when thepacket source and destination are physically located on nearby networks.

Mobile IP also places burdens and restrictions on the client device. Theclient must install additional software to enable discovering the FA. Aparticular client is limited to communicating with only one FA at atime. This means that there is no provision for dividing the load amongmultiple FAs. If the FA fails, then all state information about theclient is lost, and the client must re-establish all of its networkconnectivity. Furthermore, all clients must be assigned to a publiclyroutable (global) IP address. In today's Internet, such addresses areseverely limited, so this represents a difficult limitation,particularly for large organizations with many mobile workers.

An end-to-end TCP re-mapping solution proposed by Alex Snoeren and HariBalakrishnan is detailed in their paper, “An End-to-End Approach to HostMobility,” Proceedings of MobiCom 2000, August 2000. Recognizing thelimitations of Mobile IP, these authors suggest that seamless mobilitycan be achieved by adding additional mechanisms to TCP, allowing anestablished connection to be “re-mapped” to a client's new IP address.In this way, as the client roams, it is free to obtain a new IP addressand consequently re-map all of its open connections. In this solution,the TCP/IP connection operates directly between the roaming device (withits dynamic IP address) and the server. Whenever the device roams andobtains a new IP address, messages are sent over the TCP/IP link tonotify the server that the device's address has changed.

This solution also has a number of drawbacks. It requires changes to theTCP implementations on all clients and servers, which is an unlikelyoccurrence. Applications that are aware of the device's IP address mustbe modified to learn about and handle the IP address changes that occuras the device roams. The solution does not work for User DatagramProtocol (UDP)/IP-based communication. Finally, the system relies onDynamic Domain Name Service (DDNS) to allow remote hosts to learn aboutthe client's current IP address; unfortunately, DDNS is not yet fullydeployed.

The HAWAII system is described in an Internet Draft titled “IPmicro-mobility support using HAWAII”, R. Ramjee et al., Jul. 7, 2000,which is available on the Internet at http://www.ietf.org. HAWAII is anoptimization to Mobile IP to enable a user to roam more effectivelywithin a single administrative domain. When a user roams into anadministrative domain, a relationship is established with the local FA,in the normal fashion. Within the administrative domain, roaming isaccomplished by dynamically updating routers and host routing tables sothat the FA can forward packets to and from the device.

This solution reduces the FA-HA setup and teardown overhead as comparedto Mobile IP, because the FA does not change frequently: It remainsfixed as long as the user is roaming within the administrative domainsupported by the FA. Like Mobile IP, the HAWAII technique can eliminateoutbound “triangle” routing for packets sent from the client (though notfor packets sent to the client, because the client's public address isrouted to the HA through the Internet).

However, the HAWAII technique introduces additional overhead to updaterouters (which may not be possible or permissible in many administrativedomains). It also does not eliminate the computational performance,bandwidth, and reliability problems associated with Mobile IP.

These existing solutions for host mobility are also severely limited inthat they do not provide mechanisms for enforcing policies regarding (1)which users are accessing the wired network through the wireless accessenvironment and (2) which servers those users are communicating with.

Existing security mechanisms fall into two broad categories. The firstis link-level encryption, and the second is secure IP tunneling. Each ofthese techniques will now be described.

Link-level encryption is used to ensure that data is not transmitted inthe clear over the wireless network. In the 802.11 environment, WEP(Wireless Equivalent Privacy) is defined to enable encryption betweenthe client and the wireless access point. In typical implementations, asystems administrator defines a key that is provided to all authorizedusers. Users configure their clients with this key, which is thenpresented to the access point to prove that the device is authorized toaccess the network. Once this handshake is complete, a session key isestablished so that subsequent traffic between the client and accesspoint is encrypted; this encryption is implemented within the hardwarein the wireless cards. A similar mechanism exists in Bluetoothenvironments.

This link-level security technique has several limitations. First, it isanonymous. That is, the access point (and the network) cannot determinewhich user is actually using the network. There is, therefore, no way toenforce user-based filtering and routing policies. In addition, thistechnique is cumbersome. WEP keys may be 1024 bits in length, and it iserror-prone for users to be asked to type this information. Furthermore,there is no mechanism for key revocation. Once a user has been providedwith the key, the user can no longer be denied network access. Toprevent a previously-authorized user from gaining access to the network,the administrator must create a new key, re-program all of the accesspoints, and notify all currently-authorized users to update their WEPkeys. In a large installation, this is impractical.

An alternative to using this link-level technique involves constructinga secure IP tunnel between the wireless client and some router coupledto the access point. A solution of this genre has been announced by 3ComCorporation (see http://www.3com.com/news/releases/pr00/jul0500a.html).In this particular solution, the user provides a user name and passwordto the router, which authenticates the user. Subsequently, an MPPE(Microsoft Point-to-Point Encryption) link is established between theclient and the router. In this way, the user is able to ensure that allpackets are encrypted over the wireless network.

This technique, however, is unable to take advantage of the hardwareencryption capabilities provided in the wireless access hardware,because the encryption function resides above the link level. Inaddition, the network administrator cannot use this mechanism to enforceaccess control or filtering policies on the network. Though suchfiltering could be integrated into the router itself, there is nomechanism to ensure that all clients establish secure tunnels with therouter. It is possible to implement a filtering solution by directlywiring the router to every wireless access point (so that the router cantherefore intercept all inbound and outbound traffic). However, thislatter approach imposes a significant wiring burden and is thereforeimpractical.

Accordingly, what is needed is a technique for supporting host mobilitythat overcomes the limitations of prior art techniques.

SUMMARY OF THE INVENTION

The present invention is directed to methods, systems, and computerprogram instructions for supporting host mobility in short-rangewireless computing networks. The disclosed routing techniques providefor maximum performance and throughput of the underlying routinginfrastructure, minimize network latency for packets, and providemaximal configuration flexibility. Furthermore, the disclosed secureaccess techniques enable providing a secure, managed network environmentin which per-user access controls and traffic filtering policies can beeasily and efficiently enforced. Using these techniques, a client devicecan travel seamlessly through a wireless network (such as an in-buildingnetwork) using a constant device address.

According to an embodiment of the present invention, each networkconnection is associated with a Home Agent Masquerader (HAM). Theroaming device communicates through a Foreign Agent Masquerader (FAM)which, in turn, communicates with the HAM for each active connection. Byenabling a client device to use different HAMs for each of its activeconnections, the HAM for a roaming device can be placed very close tothe physical location where the client was at the time the connectionwas established. If the connection is short-lived and the user does notactually roam while the connection is in progress, no obscure routingpaths of the type required in the prior art need to be constructed: thedevice simply uses the (nearby) HAM. In actual practice, mostconnections tend to be short-lived (e.g. to make requests from theInternet), so the disclosed technique is particularly advantageous. Forsituations in which connections are long-lived (or are expected to belong-lived), a technique is defined for placing the HAM function at amore centralized location. Connection state is loaded into each FAMincrementally, as the FAM learns of new devices for which it needs toprovide packet routing, thereby further improving overall systemperformance. An efficient and incremental handoff processing techniqueis defined. The resulting system is highly scalable, and achieves highperformance.

To complement these routing techniques, also disclosed are securitymechanisms for ensuring user-centric link-level security in short-rangewireless networking environments. The disclosed mechanisms allowpolicy-driven packet filtering to occur while supporting user-basedauthentication, and while taking advantage of the existing encryptionfacilities provided by the device hardware at each endpoint.

The features and advantages described herein are not all-inclusive and,in particular, many additional features and advantages will be apparentto one of ordinary skill in the art in view of the figures anddescription. Moreover, it should be noted that the language used in thespecification has been principally selected for readability andinstructional purposes, and not to limit the scope of the inventivesubject matter

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 illustrates the format of a Network Address Translation (NAT)table, as used in the prior art;

FIG. 2 depicts the translation technique used by prior art NAT systems;

FIG. 3 depicts the logical components in a system according to anembodiment of the present invention;

FIGS. 4 and 5 illustrate the format of a Foreign Address Masqueradertable and a Home Address Masquerader table, respectively, according toan embodiment of the present invention;

FIG. 6 provides a flowchart that depicts the logic with which packetstransmitted by a client are delivered to a destination server, accordingto an embodiment of the present invention;

FIG. 7 provides a flowchart that depicts the logic with which packetstransmitted by a server are delivered to a client, according to anembodiment of the present invention;

FIG. 8 illustrates the format of a connection table maintained by arouting coordinator (referred to equivalently herein as a roamingcoordinator), according to an embodiment of the present invention;

FIG. 9 provides a flowchart that depicts the logic that handlesestablishment of a new connection, according to an embodiment of thepresent invention;

FIG. 10 provides a flowchart that depicts the logic invoked when apacket arrives for a device that may be roaming on an existingconnection or that may be establishing a new connection, according to anembodiment of the present invention;

FIG. 11 provides a flowchart depicting logic that may be used as analternative to that of FIG. 10;

FIG. 12 provides a flowchart that depicts the logic with which thechanging location of a client device is dynamically learned, accordingto an embodiment of the present invention;

FIG. 13 provides a flowchart that depicts the logic used to preventpackets destined for a client from being sent to a routing device withwhich the client is no longer associated, according to an embodiment ofthe present invention;

FIG. 14 depicts a secure managed environment and a filtering techniquethat may be used to provide user authentication, according to anembodiment of the present invention; and

FIG. 15 provides a flowchart that depicts the logic with which a securelink may be established, according to an embodiment of the presentinvention.

DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS

The present invention will now be described more fully hereinafter withreference to the accompanying drawings, in which a preferred embodimentof the invention is shown. Like numbers refer to like elementsthroughout.

The present invention is described below with reference to flowchartillustrations of methods, apparatus (systems), and computer programinstructions embodied on one or more computer readable media accordingto an embodiment of the invention. As will be obvious to one of ordinaryskill in the art, these flowcharts are merely illustrative of the mannerin which a preferred embodiment of the present invention may beimplemented, and changes may be made to the logic that is illustratedtherein (for example, by altering the order of operations shown in somecases, by combining operations, etc.) without deviating from theinventive concepts disclosed herein.

The present invention builds upon the use of Network Address Translation(NAT), which is well-known by those skilled in the art. Using NAT allowsa particular client's network address to be “masqueraded” with someother address. This capability has traditionally been used to enablemultiple private client addresses within a corporate network to beexposed to the Internet using a smaller number of publicly visibleaddresses. This reduces the number of global IP addresses that need tobe obtained, and it enhances network security.

To accomplish this masquerading, a device providing NAT maintains anaddress translation table, with one entry for each establishedconnection, as shown in FIG. 1. When a connection is established (e.g. aTCP SYN message is sent), the NAT host establishes an entry in the tablecorresponding to the client and server host addresses and ports. It alsoassigns a masquerading IP address and port, which are the “public” viewof the client host for the lifespan of the connection. (Thus, for aparticular client communicating with a first server, a firstmasquerading address and port may be used, while for this same clientcommunicating with a different server, a different masquerading addressand port may be used.)

The operation of the NAT is shown in FIG. 2. Any outbound packets sent210 from a client 205 on a particular connection (using a source IPaddress set to the client's address and port number, and a destinationIP address set to the server's address and port number) are forwarded220 from the NAT 215 as if they were sent by the masquerade address andmasquerade port number. Server 225 therefore believes it iscommunicating with a client having this masquerade address and portnumber. Thus, any inbound packets 230 from server 225 that are destinedfor the masquerade address and masquerade port are forwarded 240 by theNAT 215 as if they are destined to the actual client address and clientport of client 205.

Reference is now made to FIG. 3, which shows the logical components ofthe system described in the present invention: (1) devices 330, (2) HomeAddress Masquerader (HAM) 310, (3) Foreign Address Masquerader (FAM)340, (4) roaming coordinator 320, and (5) application server 300. Eachof these components will now be described, as it pertains to the presentinvention.

Devices 330 used with the present invention (such as laptop computers,handheld computers, PDAs, cellular phones, etc.) are each equipped witha communications capability (preferably, a short-range wirelesscommunications capability). The communications capability may includetechnologies such as 802.11, Bluetooth, HomeRF, or similar technologies(which may be as yet undeveloped). The network capability may be builtinto the device. Or, it may be made available in another manner,including but not limited to: via a plug-in card (such as a PCMCIA, orPersonal Computer Memory Card International Association, card), or byattaching a dongle (that is, a plug-in device that attaches to a USB, orUniversal Serial Bus, port or to an RS232 port).

All packets sent to and from a client device 330 pass through a FAM 340.The device's outbound packets 350 a are forwarded 350 b by the FAM tothe destination server 300. Inbound packets from server 300, on theother hand, are first sent 360 a to the device's HAM 310, and are thenforwarded 360 b to the FAM 340, which sends them 360 c to the device330.

In the preferred embodiment, a HAM 310 is statically assigned to eachconnection between a particular client device and server (although adevice's HAM may be changed, as described in more detail below). Tosupport routing, the HAM employs a HAM translation record (describedbelow with reference to FIG. 5). In the preferred embodiment, the HAM isimplemented within a network access point, router, or bridge, althoughas described below, it may alternatively be implemented within a centralserver or other host.

In the preferred embodiment, the FAM 340 is the first (non-bridging)network element that communicates with the device. Packets sent to andfrom the device must pass through the FAM. Preferably, the FAM isimplemented within a network access point or a LAN router. (Inalternative embodiments, FAM capabilities may be put in bridges,provided that every client communicates with a FAM-enabled bridge.) TheFAM changes as the device roams. To support routing, the FAM employs aFAM translation record (described below with reference to FIG. 4).Preferably, the initial FAM also performs the role of HAM for thedevice, as described below, although this is not required by the presentinvention.

Application server 300 is the endpoint with which the device iscommunicating. This remains constant for the duration of the connection.(Alternatively, the application server itself may be a mobile deviceassociated with its own FAM and HAM. This requires that static, publiclyroutable addresses are used as masquerading addresses for well-knownservices.)

Roaming coordinator 320 enables HAM and FAM connectivity and discovery,as well as connection migration (i.e. handoff). In the preferredembodiment, the roaming coordinator is implemented within a servercomputer that is network-connected to the various network access pointsin the system.

According to the present invention, the HAM and FAM enablelocation-independent packet routing using techniques that are based onthe concepts of network address translation. To accomplish this, the HAMand FAM maintain a HAM translation record and FAM translation record,respectively, for each connection that they are supporting. The HAMtranslation records are collectively stored in a HAM translation table,and the FAM translation records are collectively stored in a FAMtranslation table, as will now be described.

The format of a FAM translation record used in a preferred embodiment ofthe present invention is shown in FIG. 4. A FAM translation table allowsthe FAM to rewrite outbound packets on a connection from a client as ifthey originated from a masquerading address and masquerading port thatare assigned by the HAM. Upon receiving a packet from a client (see 350a of FIG. 3), the client (source) and server (destination) addresses andport numbers are used (preferably as an index) to retrieve acorresponding FAM translation record, and the masquerading address andport number stored therein are substituted for the client's actualaddress and port number (as described in more detail below withreference to FIG. 6). The FAM translation record also allows the FAM toforward inbound packets (see 360 c) to the client address and port byretrieving the stored record having the matching FAM address and portnumber (and, therefore, the masquerading address and port number), andsubstituting the client as the destination in place of the FAM (asdescribed in more detail below with reference to FIG. 7).

Note that while the example table formats shown in FIGS. 4, 5, and 8include an entry for a protocol identifier, this information is optionaland is required only in a system supporting multiple protocols (such asboth TCP and UDP). It is also understood that the tables may containmore fields than are illustrated in FIGS. 4, 5, and 8, without takingaway from the inventive concepts herein.

The format of a HAM translation record used in a preferred embodiment ofthe present invention is shown in FIG. 5. These HAM translation recordsallow the HAM to forward inbound packets to the appropriate FAM thatcan, in turn, forward the packets to the client. Upon receiving aninbound packet (see 360 a) from a server, the HAM uses the masqueradingaddress and port number, and retrieves a HAM translation record whoseserver address and port number match those contained in the packet. TheFAM address and port stored therein are then substituted for themasquerading address and port, and the packet is forwarded (see 360 b)to this FAM.

Though not shown in FIG. 5, alternative embodiments of the HAMtranslation record optionally may include (1) the actual client addressand client port associated with the connection, which are known to theHAM when it assigns a masquerading address and port for the connection,and/or (2) multiple FAM addresses and FAM ports within each entry.

Multiple FAM addresses and ports may be present in two cases. First,when a client is roaming from one FAM to another, multiple FAMs may betemporarily associated with the connection. In addition, a client may becapable of communicating with multiple network access points or routersat once, even while stationary. It may therefore establish relationshipswith multiple access points, and send packets to and from the networkthrough these access points. Therefore, multiple FAMs may exist for aparticular connection, all of which are capable of forwarding a packetto the client. When more than one FAM is available for routing aparticular packet, the HAM may select from the available FAMs usingconflict resolution techniques (including selecting a FAM randomly) thatdo not form part of the present invention. (Preferably, the existence ofmultiple FAMs is also known from entries in the connection routingtable, to be described below with reference to FIG. 8.)

FIG. 6 depicts a flowchart showing how a packet is transmitted from aclient to a server according to a preferred embodiment of the presentinvention. This processing corresponds to flows 350 a and 350 b of FIG.3. At Block 600, the client transmits an IP packet whose source is theclient's IP address and port and whose destination is the server's IPaddress and port. This packet may be a packet in an already-establishedconnection, or a connect request packet (such as a TCP SYN, or the firstpacket in a UDP stream). The packet is transmitted on a link thatreaches the client's current FAM. (The FAM's MAC address is placed inthe packet as the destination MAC address. This MAC address is known tothe client using prior art techniques such as the Address ResolutionProtocol, or “ARP”. Alternatively, a broadcast MAC address may be used.)At Block 610, the FAM receives the packet and extracts the sourceaddress and port and the destination address and port from the packet.At Block 620, the FAM accesses the FAM translation table to retrieve aFAM translation record (see FIG. 4) whose client and server address andport match those of the extracted source and destination from Block 610.

At Block 630, it is determined whether a matching FAM translation recordwas found. If the answer to Block 630 is no, then at Block 670 the FAMcontacts the routing coordinator to determine whether a connectionbetween this client and this server already exists, and to establish aFAM translation record for it. (This process is detailed in FIG. 10.) Atdecision Block 675, it is determined whether the FAM translation recordwas created. If the answer to decision Block 675 is no, then this packetrepresents a (potential) new connection, which is handled (Block 680) inaccordance with FIG. 9 (wherein the FAM will attempt to also become theHAM). The process continues at Block 690, where it is determined whetherthe FAM translation record was created. If the answer to decision Block690 is no, then the packet is discarded, and the process terminates atBlock 695. (In alternative embodiments, the check at decision Block 690may be avoided, in which case the packet is always discarded, with theprocess directly terminating at Block 695. While this alternativediscards the client's connect request packet, the protocolimplementation in the client will typically detect this dropped packetand retransmit it. The retransmitted packet will be automaticallyprocessed in the proper manner by the logic as presented in theflowcharts.)

If the answer to decision Block 630 is yes (i.e. the FAM already knowsabout this connection), or if the answer to decision Block 675 is yes(i.e. this is a roaming device which is already known to the routingcoordinator and which has just come into contact with this FAM), or ifthe answer to decision Block 690 is yes (i.e. this is a new connectionfor this device), then a valid FAM translation record has been located(or generated) for this packet. Control passes to Block 640, where themasquerading address and port are extracted from the FAM translationrecord. At Block 650, these addresses are inserted (i.e. substituted) asthe source address and port in the packet, and at Block 660, therewritten packet is transmitted on the network. The process terminatesat Block 695.

In this way, packets transmitted by the client are forwarded to theserver so that the server sees the source as being the masqueradingaddress and port, instead of the actual client's address and port.Moreover, the address translation technique within the FAM of thepresent invention enables efficiently processing these outbound packets.

Now referring to FIG. 7, there is shown a flowchart depicting howpackets transmitted by the server are delivered to the client accordingto a preferred embodiment of the present invention. This corresponds toflows 360 a, 360 b, and 360 c of FIG. 3. At Block 700, the servertransmits an IP packet whose source address and port identify the serverand whose destination address and port are the masquerading address andport associated with the connection. The server uses the masqueradingaddress and port because all packets generated by the client wererewritten by the FAM (see FIG. 6) to use this address and port, and theserver therefore believes this to be the address and port of the clientwith which it is communicating.

At Block 705, this packet is received by the HAM for the correspondingconnection, and the HAM extracts the source (server) and destination(masquerading) addresses and ports from the packet. (As will bedescribed below with reference to FIG. 9, the HAM is responsible forgenerating the masquerading address and port, so that packets sent tothe masquerading address and port will arrive at the HAM through normalIP routing means.) At Block 710, the HAM searches the HAM translationtable to locate a HAM translation record (see FIG. 5) matching theserver address and port and masquerading address and port extracted fromthe packet. At decision Block 715, it is determined whether a HAMtranslation record was found. If the answer to decision Block 715 is no,then the HAM is not associated with a connection between the server andthe client, so at Block 785, the packet is discarded. Processing thencompletes at Block 795.

Note that the flowcharts of the preferred embodiment are described assimply discarding packets in a number of error situations, whichtypically correspond to situations in which the client is activelymoving and the tables have not yet been updated to reflect the client'snew location. Upper layers of the protocol stack on the client willtypically detect the discarded packets and provide remedial measuresaccording to the prior art. An implementation may choose to also loginformation about these dropped packets. In particular, it may bedesirable to log information when a transition is being made from Block715 to Block 785, as this transition should not typically occur and mayrepresent a denial-of-service attack. (Or, it may occur simply becausethe client has failed or left the domain without notifying its HAM orits most-recent FAM, or a timeout may have occurred that caused deletionof a UDP-based HAM translation record.)

Continuing with FIG. 7, if the answer to decision Block 715 is yes, thenthe HAM knows about this masquerading client, and at decision Block 720,it is determined whether the retrieved HAM translation record contains anon-nil FAM address and port. (The FAM information in the HAMtranslation record is nil when the HAM does not yet know which FAM iscurrently handling this masquerading client.) If the answer to decisionBlock 720 is no (i.e. there is no FAM assigned), then at Block 725, theFAM address and port are obtained from the routing coordinator inaccordance with the algorithm shown in FIG. 12. (The FAM address andport are initially provided by the FAM to the routing coordinatoraccording to FIG. 10; see Blocks 1010-1050.) At decision Block 730, itis determined whether a FAM address and port were obtained through thisprocess. If the answer to decision Block 730 is no, then the client isnot currently associated with any FAM. Control passes to Block 785,where the packet is discarded, and the process completes at Block 795.

In alternative embodiments, the HAM may choose not to perform a query tothe routing coordinator, as depicted in Block 725, if it has performed asimilar query on the same connection within a recent time period (wherethe time period may be a statically configured value or may bedynamically determined based on how long the connection has been withoutan associated FAM); in this case, the HAM proceeds to block 730 andbehaves as if it did not receive a response from the routingcoordinator. This alternative embodiment reduces the load on the HAM andthe routing coordinator when frequent traffic is arriving on aconnection for a client that is currently out-of-coverage.

Still referring to FIG. 7, if the answer to decision Block 720 is yes(i.e. there is a non-nil FAM entry in the HAM translation record) or theanswer to decision Block 730 is yes (i.e. the FAM information wasobtained from the routing coordinator), then the HAM has located a validHAM translation record and a non-nil FAM address and port. (When the FAMis identified through the routing coordinator at Block 725, theprocessing of FIG. 12 revises the HAM translation record to rememberthis FAM information for subsequent use. See Block 1250.) At Block 735,the HAM rewrites the destination address to be the FAM address and portfound in the HAM translation record. At Block 740, the rewritten packetis transmitted on the network, now destined for the FAM. At Block 745,the FAM receives the packet and extracts the server (source) address andport and FAM (destination) address and port from the packet. At Block750, the FAM searches its FAM translation table to locate a FAMtranslation record matching the server address and port and FAM addressand port that were extracted in Block 745. At decision Block 755, it isdetermined whether a matching FAM translation record was found. If theanswer to decision Block 755 is no, then the client is no longerassociated with this FAM, and the packet is therefore discarded (Block790), and the processing completes at Block 795.

Continuing with FIG. 7, if the answer to decision Block 755 is yes, thenthis client is still using this FAM, and at Block 760 the FAM rewritesthe packet's destination address to be the client address and port foundin the FAM translation record. At Block 765, the rewritten packet istransmitted on the outbound link that is bound to the clientdestination. The process then completes at Block 795.

In this way, the server directs traffic to the masquerading address, andthe HAM and FAM cooperate to route the packet to the client at itscurrent location. If the client has moved such that it is now handled bya FAM different from that used previously for this connection, the newFAM is automatically and efficiently located by the HAM (in cooperationwith the routing coordinator). Moreover, by applying NAT techniques, theperformance of the HAM and FAM is maximized, and additional packet loss,fragmentation, and error conditions introduced by prior art mobile hostsolutions are eliminated.

When a connection is established (e.g. the first packet on a TCPconnection or UDP stream is sent between a client and a server), a setupprocess is performed whereby the HAM is assigned and an initial FAM isdesignated. (As used herein, a UDP “connection” is defined as a sequenceof UDP packets transmitted between a client address and port and aserver address and port; because UDP is connectionless, the connectionis implicit—according to the preferred embodiment, it ends when notraffic has been sent on the connection within some timeout period.) Asa user roams about the network, the connection may need to be associatedwith different FAMs located near the user. This roaming requires thatthe FAM be designated, that the FAM learns about the masqueradingaddress and port for the connection (in order to provide NAT services asdescribed above with reference to FIG. 6), that the FAM assign anaddress and port for the connection, and that the HAM be notified aboutthe FAM's address and assigned port for the connection. These exchanges,which establish and maintain the content of the HAM and FAM translationrecords, are coordinated through a routing coordinator. The functionsinvolved in connection setup and roaming will now be described withreference to FIGS. 8 through 13.

The routing coordinator maintains a connection table, which holds oneconnection table record for each active TCP or UDP connection. FIG. 8illustrates an example of the format of a connection table record,according to a preferred embodiment of the present invention. Theconnection table record holds the client and server address and port,the masquerading address and port, and the identity (e.g. networkaddress) of the HAM. In addition, each connection table record includeszero or more FAM records, each containing the FAM identity (e.g. networkaddress) and address and port assigned to the connection by the FAM. Theconnection table record may include multiple FAM records, one for eachof the FAMs that the client is currently using to transmit packets onthis connection. (Refer to the previous discussion of situations inwhich more than one FAM may be provided for a particular connection.)

FIG. 9 provides a flowchart depicting how a connection is establishedwhen a packet is first transmitted by a client to a server, according toa preferred embodiment of the present invention. (As shown in FIG. 6,this processing occurs when the FAM has received a packet sent by aclient, but the FAM cannot locate a FAM translation record either in itsown FAM translation table or by contacting the routing coordinator.)Block 900 determines which host will serve as the HAM for this newconnection. In the preferred embodiment, this role is played by the hostthat first receives and processes the outbound packet (i.e. the FAM).However, in alternative embodiments, it may be desired that the HAM rolebe played by the routing coordinator or some other fixed host. Or,another host may be selected, perhaps using dynamic factors (e.g. a hostthat is possibly located closer to the user's usual location, in theuser's office, or within the user's own administrative domain) where thevalues of such dynamic factors are located using prior art techniques.(For example, a MAC address may be associated with a user in a storedtable, or a user may be identified from information transmitted duringan authentication or link establishment process. The user'sidentification may then be used to consult a configuration orpreferences table, which may contain entries that can be used in thedynamic selection process.) This decision to designate a HAM other thanthe FAM that first receives the connection might occur according to anadministrative policy, for example to reduce CPU or network load on theaccess points. Alternatively, it may be expedient to move long-livedconnections to a central server to mitigate the risk of state loss werean access point to fail or be switched off. This HAM assignment policymay be made based on the network port that the connection is using; forexample, connections to the TELNET port (port 23) might be automaticallypassed to the routing coordinator.

At decision Block 910, it is determined whether the designated HAM hostis the local host. If the answer to decision Block 910 is no, then atBlock 980, the designated HAM host is notified of the client and serveraddresses and ports for the connection; that HAM host, upon receivingthis notification, executes the algorithm of FIG. 9. After notifying theHAM host, processing terminates at Block 990. This re-directing HAM willnow become a FAM for the client, and will subsequently learn themasquerading information for the client from the routing coordinator inthe usual way (according to the algorithm of FIG. 10).

Note that the subsequent invocation of FIG. 9 by the re-directed hostalso allows selection of a different HAM host. It must be ensured thatthe selection policy in an implementation will terminate withoutencountering an infinite loop. (Because the handoff policy of thepresent invention is globally administered, an infinite loop should notoccur.)

If the answer to decision Block 910 is yes, then processing continues atBlock 920, where the local HAM host selects a masquerading address andport for the connection between the client and server. The masqueradingaddress must be an address that will route packets to this local HAMhost, according to existing IP routing techniques of the prior art. Theport must not be shared by any other active connection. (In thepreferred embodiment, the port is not reused by a new connection untilsome duration has elapsed since the termination of a prior connection.This eliminates the possibility that stale packets from the previousconnection may accidentally get routed onto the new connection.)Preferably, the masquerading address is the public address of the HAMitself, such that the uniqueness must be provided through selection of aunique port number. Alternatively, a HAM may have multiple publicaddresses, and may assign port numbers from all of them. Thisalternative approach provides additional scalability (because a largerrange of address and port combinations is available for assignment, moreconnections can be supported). In addition, if the HAM is amulti-processing host, use of multiple masquerading addresses enablesassigning different processors to each address.

At Block 930, the HAM notifies the routing coordinator about the newconnection (providing the client address and port, the server addressand port, masquerading address and port, and HAM identity). At Block935, upon receiving this notification, the routing coordinatorestablishes a connection table record for the connection (where thisrecord initially has no FAM records within it). At Block 940, the HAMcreates a HAM translation record for the connection and inserts therecord into the local HAM translation table. (As noted earlier, the HAMtranslation table records of the preferred embodiment do not include theoriginating client's address and port, although in alternativeembodiments this information may also be stored.) The FAM address andport are set to nil in this newly-created record. Control then passes toBlock 950, where the local HAM host establishes itself as a FAM for theconnection (according to the logic of FIG. 10). The process thenterminates at Block 990.

Referring now to FIG. 10, there is shown a flowchart depicting apreferred embodiment of the steps taken when an access point (or routeror bridge) first receives packets from a client on a connection forwhich no FAM translation record exists. This situation may arise, forexample, when the client is roaming and is transmitting packets on analready-established connection that used a different FAM. As shown inFIG. 6, the FAM must receive information about the masquerading addressand port in order to create a FAM translation record and then use it toforward the packet. Because the connection is already established, a HAMhas already been assigned, along with a masquerading address and port.This situation also arises for a new connection (in which case FIG. 10is invoked from FIG. 9), in order to set the initial FAM.

At Block 1000, the FAM allocates a FAM address and port number for thisconnection between the client and server. The allocated address must benetwork routable to the FAM host from any potential HAM. The FAM addressand port combination must not be already allocated to some otherconnection for which the FAM host is serving as FAM or HAM. Preferably,the FAM address is the address of the FAM itself, such that theuniqueness must be provided through selection of a unique port number.Alternatively, a FAM may have multiple addresses, and may assign portnumbers from all of them. This alternative approach provides additionalscalability (because a larger range of address and port combinations isavailable for assignment, more connections can be supported). Inaddition, if the FAM is a multi-processing host, use of multiple FAMaddresses enables assigning different processors to each address.

The generated FAM address and port combination are communicated to therouting coordinator (and subsequently to the HAM—see FIG. 7). Becausethe FAM address and port are unique to the connection, the FAM can usethat combination to uniquely identify the correct FAM translation recordto be applied to packets destined for the client—and hence which clientaddress and port to use. In the preferred embodiment, both the serveraddress and port, and the FAM address and port, are checked when the FAMaccesses its FAM translation records, to ensure that spurious packetsare not forwarded to the client (although the client would typicallysimply discard such packets, if received). However, if it is known thatthe FAM address is constant, an alternative embodiment may omit storingand/or comparing the FAM address within its own FAM translation table.

At Block 1010, the FAM transmits a request to the routing coordinator tobecome the current FAM. This request includes the client address andport, the server address and port, the FAM identity, and the FAM addressand port. (The client address and port and server address and port wereextracted by the FAM in Block 610 of FIG. 6 from the packet transmittedby the client.) At Block 1020, the routing coordinator receives the FAMrequest and extracts its parameters. The routing coordinator thensearches (Block 1030) the connection table for a connection table recordwhose client address and port and server address and port match thoseprovided by the FAM for this connection. At decision Block 1040, it isdetermined whether a matching connection table record was found.

Continuing with FIG. 10, if the answer to decision Block 1040 is no,then (according to the present invention) this is not an existingconnection between this client and server, and a notification isreturned (Block 1070) to the FAM to indicate that the request isrejected. At Block 1080, the FAM deallocates the FAM address and portprovided in its request, and the process terminates at Block 1090.

Still referring to FIG. 10, if the answer to decision Block 1040 is yes,then the routing coordinator adds a new FAM record to the connectiontable record (Block 1050). This FAM record includes the FAM identity andFAM address and port provided in the FAM request sent at Block 1010. Ifone or more FAM records are already present in the connection tablerecord, the routing coordinator may insert this new FAM record in anorder that is best suited to a particular system in which the presentinvention is implemented. For example, new FAM records may be entered inFIFO (First-In, First-Out) order, or in an order based on a policy suchas a prediction of which FAM the client is most likely to use in theimmediate future (where this information may be determined usinghistorical analysis techniques that do not form part of the presentinvention).

At Block 1060, the Routing coordinator sends a reply to the FAM andprovides the HAM identity (e.g. its network address) and themasquerading address and port associated with the connection. At Block1065, the FAM receives the routing coordinator response and creates aFAM translation record containing the information provided by therouting coordinator. The process then terminates at Block 1090. The HAMwill dynamically learn of this new FAM according to the logic of FIG. 7,upon receiving a packet destined for the client's masquerading addressand port, and will automatically forward the packet to the appropriateFAM.

Note that although FIGS. 9 and 10 depict particular embodiments of theHAM assignment and FAM translation record creation processes,respectively, it is understood that alternative embodiments mayimplement these processes differently without deviating from theinventive concepts disclosed herein. For example, the process of FIG. 10could be re-implemented as a two-phase request between the FAM and therouting coordinator. In the first request, the FAM queries the routingcoordinator to determine whether the connection exists (i.e. whether aHAM has already informed the routing coordinator of the connection), andin the second request, the FAM provides a FAM address and port to assignto the connection. In this way, the FAM does not need to allocate a FAMaddress and port until it is sure that the connection table recordexists (thereby eliminating the deallocation step of Block 1080).

As shown in FIG. 6 (Block 670), the process of FIG. 10 is first executedby a FAM to determine whether the connection already exists (and, if so,to establish a FAM translation record for it); if the connection doesnot already exist (i.e. the answer to the decision in Block 675 is no),the process of FIG. 9 is executed to establish a HAM (and create a newconnection table record). An alternative embodiment may optimize thesequence when the process of FIG. 10 is executed immediately prior tothe process of FIG. 9. For example, once it is determined that aconnection table record does not exist for the FAM request (i.e. theanswer to the decision in Block 1040 is no), then the routingcoordinator can immediately begin processing the FAM request as a HAMestablishment request; in this case, the requesting FAM becomesdesignated as the HAM for the connection. This alternative process isillustrated in FIG. 11. The sequence of Blocks 1100, 1110, 1120, 1130,1140, 1150, 1160, 1165, and 1190 match the “normal” processing path ofFIG. 10. However, at decision Block 1140 (corresponding to Block 1040),if the routing coordinator determines that no connection table recordexists for the connection, control passes to Block 1170. The routingcoordinator determines that because this is a new connection, the hostthat requested to become a FAM should, in fact, be designated as the HAMfor this connection. The provided FAM address and port become themasquerading address and port for the connection, and a connection tablerecord is created. At Block 1175, the requesting FAM is notified that ithas become the designated HAM for the connection. At Block 1180, therequesting FAM (now the HAM) creates a HAM translation record for theconnection. The process then returns from Block 1185 to Block 1100 inorder to establish the local FAM translation record for thenewly-registered connection.

In yet another alternative embodiment of the present invention, theprocess of FIG. 10 might be re-implemented as a direct communicationbetween the FAM and the HAM. For this to occur, the routing coordinatormust broadcast the identity of the HAM whenever a new connection tablerecord is created (according to the process of FIG. 9). This solutionreduces the processing load on the routing coordinator at the expense ofadditional network bandwidth consumption and additional load on the HAM.

Referring now to FIG. 12, there is shown a flowchart depicting how theHAM retrieves information about the current FAM address and port thatare associated with a connection. The HAM has received a packet from aserver, and needs to know which FAM the packet should be forwarded to.(This process is invoked from Block 725 of FIG. 7, when the HAM has aFAM translation record matching the server address and port number andthe masquerading address and port number, but the FAM address and portwithin that record are set to nil values.) At Block 1200, the HAM issuesa request to the routing coordinator. This request includes themasquerading address and port. (Alternatively, if the HAM translationrecord includes the client address and port, the HAM could firstdetermine the client address and port for the inbound packet and providethat information and the server address and port instead of, or inaddition to, the masquerading address and port.) At Block 1210, therouting coordinator receives the HAM request and extracts the parametersfrom the request. The routing coordinator then searches (Block 1220) theconnection table for a connection table record whose masqueradingaddress and port (and server address and port and client address andport, if this information is provided) match those provided by the HAM.(Preferably, the routing coordinator uses the masquerading address andport as a key to index its connection table, although the server andclient information may also be used. Upon locating a matching recordwhen only the masquerading information is used, the routing coordinatorpreferably verifies the server address and port against the extractedvalues. A mismatch indicates an error condition, such as asignificantly-delayed packet, a replay attack, or a fraudulent packet.)

At decision Block 1230, it is determined whether a matching connectiontable record was found.

Still referring to FIG. 12, if the answer to decision Block 1230 is no,then an error has occurred, and at Block 1280, an error message isreturned to the HAM. At Block 1285, the HAM receives the error response.The process completes at Block 1295. Though not shown in the figure, itis understood that the HAM may optionally perform various operations tohandle this error. For example, it may delete the HAM translation recordcorresponding to the connection and re-establish itself as the HAM inaccordance with the procedure in FIG. 9.

Continuing with FIG. 12, if the answer to decision Block 1230 is yes(i.e. the routing coordinator knows about this connection), then atBlock 1240, the routing coordinator generates a response message to theHAM. This response message contains a list of the FAM records containedwithin the connection table record. At Block 1250, the HAM receives theresponse message and updates the HAM translation record to reflect thereceived FAM address and port (if any). The process then terminates atBlock 1295.

Preferably, when the routing coordinator finds more than one FAM recordduring the processing of Block 1220, all such entries are communicatedto the HAM at Block 1240. The HAM may then use one or all of these (e.g.based on an implementation-specific policy) to update its HAMtranslation record. Alternatively, the routing coordinator may selectsome subset of the located FAM records, using a selection algorithm suchas an implementation-specific policy, and transmit this subset at Block1240. When using this alternative technique, the routing coordinator isable to selectively control which FAM(s) are exposed to the HAM.

In the preferred embodiment, the HAM learns about FAM address and portassignments on an “as-needed”, incremental basis (i.e. by invoking thetechnique of FIG. 12 from Block 720 of FIG. 7). However, in alternativeembodiments of the present invention, the routing coordinator mayinitiate (or “push”) the transmission of the FAM information directly tothe appropriate HAM. For example, upon the completion of the processshown in FIG. 10 (wherein a new FAM record is added to the connectiontable record at Block 1050, the connection table record having beeninitially created upon a notification from the HAM at Block 930 of FIG.9), the routing coordinator might immediately notify the HAM about thenew FAM. In other alternative embodiments of the present invention, therouting coordinator may buffer FAM updates and push multiple FAM updatesin a single notification; this notification may be unicast, multicast,or broadcast. In yet other embodiments of the present invention, whenthe HAM requests FAM information for a particular connection, therouting coordinator may choose to provide, in the response, informationabout other relevant FAM updates that have occurred to other connectionsthat the HAM is managing.

When a client is no longer in communication with a FAM, that FAM mustensure that no future packets will be routed to it by the HAM;otherwise, those packets will assuredly be lost (see Block 790 in FIG.7). Referring now to FIG. 13, there is shown a flowchart that depicts apreferred embodiment of the steps taken when a client terminates itscommunication with the FAM. This connection termination may be explicit(for example, caused by some form of “termination”, “shutdown”, or“disconnect” message transmitted at the communication link level) orimplicit (for example, caused by a timeout when no communication hasoccurred over the link for some period of time). At Block 1300, the FAMtransmits a notification to the routing coordinator. This messagecontains the client address and FAM identity. At Block 1310, the routingcoordinator receives the notification and extracts the containedparameters. At decision Block 1320, it is determined whether there areany connection table records whose client address matches the clientaddress given in the FAM notification and which are associated with aFAM record whose FAM identifier matches the FAM identifier given in theFAM notification. If the answer to decision Block 1320 is no, then therouting coordinator will not use this FAM for requests to locate thisclient, and processing terminates at Block 1390.

Continuing with FIG. 13, if the answer to decision Block 1320 is yes,then at Block 1330, the routing coordinator deletes the FAM record(whose FAM identifier matches that in the FAM notification) from theconnection table record. In Block 1340, the routing coordinatorpreferably transmits a notification to the HAM associated with theconnection table record. This notification includes the masqueradingaddress and port and FAM address and port. (In an alternative embodimentwhere the HAM translation record stored the client address and port,this notification may use the server address and port and the clientaddress and port instead of, or in addition to, the masqueradinginformation.) At Block 1350, the HAM receives this notification andextracts the parameters. The HAM then retrieves (Block 1360) a HAMtranslation record corresponding to the masquerading address and port(and the server address and port and the client address and port, ifprovided) provided in the notification. At decision Block 1370, it isdetermined whether the HAM found a matching HAM translation record thatcontains the provided FAM address and port. If the answer to decisionBlock 1370 is yes, then in Block 1380, the provided FAM address and portare removed from the retrieved HAM translation record (that is, thefields are set to nil). Control then returns to decision Block 1320. Ifthe answer to decision Block 1370 is no, then no updates are needed tothe HAM translation table, and control returns to Block 1320. (It isunderstood that in alternative embodiments, the HAM might takeadditional actions if no HAM translation records are found for thedesignated connection; for example, the HAM might request that therouting coordinator delete the corresponding connection table recordfrom its connection table. Implementation of such optimizations will beobvious to one of ordinary skill in the art.)

In this way, when a client disconnects from a FAM, the routingcoordinator ensures that no HAMs will continue to forward packets tothat FAM on behalf of any open client connections.

Once a HAM has been assigned to a connection, that HAM continues toroute inbound packets for that connection, regardless of which FAM theclient is currently using to send outbound packets and to receiveinbound packets. However, in certain situations, it may become necessaryfor the HAM role to be migrated to a different host (such as to adifferent access point or to the routing coordinator). For example, ifthe HAM fails or is removed, then another host must take responsibilityfor the connections previously being handled by the HAM; the transfermay also be appropriate when the nature of the connection changes sothat it requires additional CPU or network bandwidth resources that canonly be provided by an alternative HAM. To accomplish this transfer, thenew HAM performs the following steps for each connection for which it isassuming the HAM responsibility.

First, the new HAM “takes over” the masquerading IP address, if it hasnot already done so. This IP address takeover ensures that packetstransmitted to the masquerading IP address will be routed to the new HAMhost. The IP address takeover process is well established in the priorart. (If the new HAM is on the same LAN as the old HAM, it simplyrequires transmission of a new ARP update so that the IP address isassociated with the new HAM's LAN address; if the new HAM is on adifferent LAN, then routing tables must be updated.)

Second, it establishes a HAM translation record for the connection. Thisis done by obtaining the necessary information from the connection tablerecord corresponding to the connection being transferred. The new HAMtranslation record must include FAM information, if a FAM record isassociated with the connection table record. (The algorithms of FIGS. 9and 10 may optionally be used to obtain the required information fromthe routing coordinator.)

Third and finally, it begins to operate as the new HAM for theconnection by using the HAM translation record to determine how toforward packets to the current FAM.

Though the flowcharts in FIGS. 6-7 and 9-13 have been shown as a serialstream of operations, it is understood that in alternative embodiments,many of these steps may occur in parallel. For example, messagetransmissions may occur using asynchronous communication, therebyallowing the sender to continue processing immediately, without waitingfor a response. This is particularly true when notifications aretransmitted.

The present invention has been described thus far without any provisionfor identifying the particular user who is sending and receiving networktraffic and without any provision for filtering the traffic generated toor from a particular client. Reference is now made to FIG. 14, whichdepicts a managed network environment that implements the presentinvention. A client authentication module 1405 is integrated into theclient 1400, and a server authentication module 1425 is integrated intothe access point 1420. When the client first communicates with theaccess point (and if no valid session key already exists between the twolink endpoints), the client authentication module communicates 1415 withthe server authentication module to provide the user's authenticationcredentials (e.g. user name and password). Once the user isauthenticated 1445 (by means of an authentication server 1450, usingtechniques of the prior art), the server authentication module and theclient authentication module negotiate a session key to enablelink-level encryption. In the preferred embodiment, this key is providedto the client by the server authentication module or alternatively, bythe authentication server; however, in alternative embodiments, theaccess point may deliver a master key (e.g. a WEP key) to the client,and the client and access point may subsequently negotiate a session keyusing the master key in the standard fashion. In this way, the client isauthenticated according to a user name and password, and thisauthentication enables provision of link-level encryption that takesadvantage of the encryption capabilities embedded in the client andaccess point hardware 1410, 1430.

Once the authentication takes place, the server authentication moduleprovides 1455 the client's MAC address, session key, and user name tothe routing coordinator 1460 over a secure channel, which stores them ina lookup table. This lookup table is used to provide the session key toany new access point with whom the client device begins communication,and it is used to enable the filtering module 1435 to identify the userfor a particular client device and, subsequently, to determine theappropriate filtering policies to apply for that user.

Still referring to FIG. 14, a filtering module 1435 is included in theaccess point 1420 so that it receives all inbound and outbound trafficto and from the client 1400. When a packet with a heretofore unseen MACaddress arrives at this filtering module, it issues a request 1465 tothe routing coordinator to determine the user's identity and obtain alist of filtering policies for that user. These policies are thenapplied to appropriately block inbound and outbound traffic. Using thistechnique, the present invention enables simply and efficientlyenforcing access control and packet filtering policies.

Referring now to FIG. 15, there is shown a flowchart depicting the stepstaken to establish a secure, managed link in accordance with a preferredembodiment of the present invention. At Block 1500, it is determinedthat a client does not have a valid link-level key for communicationwith a particular access point. This determination may occur because theclient does not have a key at present, or the access point may signal tothe client that the current key is invalid. Before rejecting the key,the access point may optionally communicate with the routing coordinatorto determine the currently valid session key for the client MAC address.

At Block 1510, the client authentication module is invoked to provideuser credentials to the server authentication module. The serverauthentication module receives these credentials (Block 1520) andprovides them to the authentication server. At Block 1530, the serverauthentication module receives a response from the authenticationserver. At decision Block 1540, it is determined whether theauthentication server response was positive.

If the answer to decision Block 1540 is no, then at Block 1590, theserver authentication module rejects the authentication and the processcompletes at Block 1595 without an established link key.

If the answer to decision Block 1540 is yes, then at Block 1550, theserver authentication module accepts the authentication request from theclient and transmits a positive response to the client authenticationmodule. At Block 1560, a session key is negotiated between the clientauthentication module and the server authentication module (assuming anegotiation process for a key value is being performed). The processthen splits into two parallel paths, one corresponding to activity atthe client and the other corresponding to activity at the access point.At Block 1570 a, the client authentication module provides thenegotiated session key to the client encryption hardware, which, inturn, uses the key to encrypt and decrypt packets sent through theaccess point. The client-side process then terminates at Block 1595. Atthe access point, at Block 1570 b, the server authentication moduleprovides the negotiated session key to the server encryption hardware,which, in turn uses the key to encrypt and decrypt packets send to theclient. At Block 1580 b, the server authentication module provides therouting coordinator with the client MAC address, session key, and username to be stored in the lookup table previously described withreference to flow 1455 of FIG. 14. The process then terminates at Block1595.

In alternative embodiments of the present invention, the system maysupport multiple types of connections, such as those over TCP and (asdescribed earlier) UDP. In this case, many of the transmissionsdescribed herein must also include a protocol identifier, and the tableretrievals must take account for the protocol ID in addition to theaddresses and ports. The manner in which the flowcharts may be alteredto provide an implementation of this type of multi-protocol support willbe obvious to those skilled in the art.

In alternative embodiments of the present invention, it is understoodthat implementations may choose to hash or otherwise encode the addressand port combinations. This encoding reduces the memory size of theinformation, thereby reducing the size of the various tables andimproving the performance of the retrieval processes. Such methods forhashing or encoding information are well known in the prior art, andtheir use within the context of the present invention will be obvious toone of ordinary skill in the art.

As has been demonstrated, the present invention provides a number ofadvantages over prior art host mobility solutions. With the presentinvention, no modification to the operating system, the networkingsoftware, nor the applications on a client device or server is requiredin order to provide location-independent packet routing and secureaccess. Packet routing for a roaming device is provided very efficientlythrough use of network address translation techniques, enabling clientdevices to use a single device address regardless of their currentlocation. Indirect, or triangular, routing is avoided for short-livedand/or non-mobile connections. While some IP header information isrewritten in packets being routed, recalculation of IP checksums can bedone easily and efficiently (e.g. by performing only a bit-wisecomparison of the changed fields, as is known in the art). Loadbalancing may be facilitated, due to performing HAM assignment on aper-connection basis rather than globally as in the prior art. A HAM maybe dynamically re-assigned, if desired, to further optimize performance.Failures of routing components are automatically detected and handled.Connection handoff is transparent to clients and servers. Bothdistributed and centralized implementations may be provided (by placingHAM functionality in access points or in a routing coordinator,respectively). User identity is explicitly determined, providing theability to filter packets sent to and from the user. This userauthentication preserves the use of existing encryption hardware on theclient and access point to establish secure links.

The related invention defines a system comprising a collection of accesspoints, wherein an IP address is assigned to a device via those accesspoints and a core server; a technique for ensuring that the IP addressstays constant, regardless of which access point a device is using at apoint in time; a technique for keeping track of which access point adevice is currently using; and a technique for exposing user locationinformation to applications. An implementation of the present inventionmay optionally be combined with an implementation of the relatedinvention, wherein the routing coordinator defined herein and the coreserver of the related invention are implemented as a single entity whichassigns dynamic addresses, handles user location tracking, and so forth(in its core role) and routes packets to those devices (in its routingcoordinator role).

The foregoing description of a preferred embodiment is for purposes ofillustrating the present invention, and is not to be construed aslimiting thereof. Although a preferred embodiment has been described, itwill be obvious to those of skill in the art that many modifications tothis preferred embodiment are possible without materially deviating fromthe novel teachings and advantages of this invention as disclosedherein. Accordingly, all such modifications are intended to be withinthe scope of the present invention, which is limited only by the claimshereafter presented (and their equivalents).

1. A method of packet routing in a short-range wireless networkingenvironment including one or more portable client devices and one ormore application servers, comprising: transmitting a packet from anapplication server to a portable client device, wherein the transmittedpacket is received at a home agent associated with the client device;forwarding, by the home agent, the received packet to a foreign agentthrough which the client device is currently communicating; receiving,by the foreign agent, the forwarded packet; and forwarding, by theforeign agent, the received forwarded packet to the client device. 2.The method of claim 1 wherein a fixed host is chosen as the home agentassociated with the client device.
 3. The method of claim 1 wherein anidentification of the client device determines which of a plurality ofhome agents is associated with the client device.
 4. The method of claim1 wherein an identification of a user of the client device determineswhich of a plurality of home agents is associated with the clientdevice.
 5. The method of claim 1 wherein a central server is selected asthe home agent associated with the client device.
 6. The method of claim1 wherein forwarding by the home agent further comprises consulting arepository to determine through which of a plurality of foreign agentsthe client device is currently communicating.
 7. A method of packetrouting in a short-range wireless networking environment including oneor more portable client devices and one or more application servers,comprising: wirelessly transmitting a packet from a portable clientdevice to an application server, wherein the transmitted packet isreceived at a foreign agent through which the client device is currentlycommunicating; and forwarding, by the foreign agent, the received packetto the application server.
 8. The method of claim 7 further comprising:consulting a repository, responsive to receiving the transmitted packet,to determine a network address and port number to be used foridentifying the client device; modifying the received packet to use thedetermined network address and port number in place of a client networkaddress and port number contained therein; and using the modified packetin the forwarding step.
 9. A method of packet routing in a short-rangewireless networking environment including one or more portable clientdevices and one or more application servers, comprising: transmittingpackets between a portable client device and an application server usingintermediary agents that transparently enable wireless roaming by atleast one of the client device and the application server from onelocation to another in the short-range wireless networking environment.10. The method of claim 9 wherein the intermediary agents enablewireless roaming by using address translation of source addresses inoutbound ones of the transmitted packets and of destination addresses ininbound ones of the transmitted packets.
 11. The method of claim 9wherein the intermediary agents include a home agent associated with theclient device.
 12. The method of claim 11 wherein a plurality of clientdevices share a particular home agent.
 13. The method of claim 12wherein the particular home agent is a central server.
 14. The method ofclaim 11 wherein the home agent associated with the client device isdetermined using administrative policy.
 15. The method of claim 11further comprising dynamically changing the home agent associated withthe client device.
 16. The method of claim 15 wherein dynamicallychanging the home agent occurs responsive to a failure of the home agentassociated with the client device.
 17. The method of claim 15 whereindynamically changing the home agent further comprises: dynamicallyassuming, by a new home agent to be associated with the client device, anetwork address used to identify the home agent that was previouslyassociated with the client device; and dynamically updating a repositorywhich records the association of the previous home agent with the clientdevice, such that the repository now records the association of the newhome agent with the client device.
 18. A system for packet routing in ashort-range wireless networking environment including one or moreportable client devices and one or more application servers, comprising:intermediary agents for transmitting packets between a portable clientdevice and an application server, and for transparently enablingwireless roaming by at least one of the client device and theapplication server from one location to another in the short-rangewireless networking environment.
 19. The system of claim 18 wherein theintermediary agents include a home agent associated with the clientdevice, and enable wireless roaming by using address translation ofsource addresses in outbound ones of the transmitted packets and ofdestination addresses in inbound ones of the transmitted packets. 20.The system of claim 19 further comprising dynamically changing the homeagent associated with the client device.